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Host Identity Protocol (HIP) Registration Extension 


Abstract 
This document specifies a registration mechanism for the Host 
Identity Protocol (HIP) that allows hosts to register with services, 
such as HIP rendezvous servers or middleboxes. This document 
obsoletes RFC 5203. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8003. 
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Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


This document specifies an extension to the Host Identity Protocol 
(HIP) [RFC7401]. The extension provides a generic means for a host 
to register with a service. The service may, for example, be a HIP 
rendezvous server [RFC8004] or a middlebox [RFC3234]. 


This document makes no further assumptions about the exact type of 
service. Likewise, this document does not specify any mechanisms to 
discover the presence of specific services or means to interact with 
them after registration. Future documents may describe those 
operations. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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Terminology 


In addition to the terminology defined in the HIP Architecture 
[HIP-ARCH], the HIP specification [RFC7401], and the HIP Rendezvous 
Extension [RFC8004], this document defines and uses the following 
terms: 


Requester: 
a HIP node registering with a HIP registrar to request 
registration for a service. 


Registrar: 
a HIP node offering registration for one or more services. 


Service: 
a facility that provides requesters with new capabilities or 
functionalities operating at the HIP layer. Examples include 
firewalls that support HIP traversal or HIP rendezvous servers. 


Registration: 
shared state stored by a requester and a registrar, allowing the 
requester to benefit from one or more HIP services offered by the 
registrar. Each registration has an associated finite lifetime. 
Requesters can extend established registrations through 
re-registration (i.e., perform a refresh). 


Registration Type: 
an 8-bit identifier for a given service in the registration 
protocol. For example, the rendezvous service is identified by a 
specific registration type. 


HIP Registration Extension Overview 


This document does not specify the means by which a requester 
discovers the availability of a service or how a requester locates a 
registrar. After a requester has discovered a registrar, it either 
initiates HIP base exchange or uses an existing HIP association with 
the registrar. In both cases, registrars use additional parameters, 
which the remainder of this document defines, to announce their 
quality and grant or refuse registration. Requesters use 
corresponding parameters to register with the service. Both the 
registrar and the requester MAY also include in the messages 
exchanged additional HIP parameters specific to the registration type 
requested. Other documents will define parameters and how they shall 
be used. 
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The HIP base exchange, including the definition of the HIP 11, R1, 
12, and R2 packets, is defined in [RFC7401]. The following sections 
describe the differences between this registration handshake and the 
standard HIP base exchange [RFC7401]. 


3.1. Registrar Announcing Its Ability 


A host that is capable and willing to act as a registrar vis-a-vis a 
specific requester SHOULD include a REG_INFO parameter in the R1 
packets it sends during all base exchanges with that requester. If 
it is currently unable to provide services due to transient 
conditions, it SHOULD include an empty REG_INFO, i.e., one with no 
services listed. If services can be provided later, it SHOULD send 
UPDATE packets indicating the current set of services available ina 
new REG_INFO parameter to all hosts it is associated with. 


3.2. Requester Requesting Registration 


To request registration with a service, a requester constructs and 
includes a corresponding REG_REQUEST parameter in an 12 or UPDATE 
packet it sends to the registrar. 


If the requester has no HIP association established with the 
registrar, it SHOULD send the REG_REQUEST at the earliest 
possibility, i.e., in the 12 packet. This minimizes the number of 
packets that need to be exchanged with the registrar. A registrar 
MAY end a HIP association that does not carry a REG_REQUEST by 
including a NOTIFY with the type REG_REQUIRED in the R2. In this 
case, no HIP association is created between the hosts. The 

REG REQUIRED notification error type is 51. 


3.3. Registrar Granting or Refusing Service(s) Registration 


Once registration has been requested, the registrar is able to 
authenticate the requester based on the host identity included in 12. 


If the registrar knows the Host Identities (HIs) of all the hosts 
that are allowed to register for service(s), it SHOULD reject 
registrations from unknown hosts. However, since it may be 
infeasible to preconfigure the registrar with all the HIs, the 
registrar SHOULD also support HIP certificates [RFC8002] to allow for 
certificate-based authentication. 


When a requester wants to register with a registrar, it SHOULD check 
if it has a suitable certificate for authenticating with the 
registrar. How the suitability is determined and how the 
certificates are obtained is out of scope for this document. If the 
requester has one or more suitable certificates, the host SHOULD 
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include them (or just the most suitable one) in a CERT parameter to 
the HIP packet along with the REG_REQUEST parameter. If the 
requester does not have any suitable certificates, it SHOULD send the 
registration request without the CERT parameter to test whether the 
registrar accepts the request based on the host's identity. 


When a registrar receives a HIP packet with a REG_REQUEST parameter, 
and it requires authentication for at least one of the registration 
types listed in the REG_REQUEST parameter, it MUST first check 
whether the HI of the requester is in the allowed list for all the 
registration types in the REG_REQUEST parameter. If the requester is 
in the allowed list (or the registrar does not require any 
authentication), the registrar MUST proceed with the registration. 


If the requester was not in the allowed list and the registrar 
requires the requester to authenticate, the registrar MUST check 
whether the packet also contains a CERT parameter. If the packet 
does not contain a CERT parameter, the registrar MUST reject the 
registrations requiring authentication with Failure Type 0 (zero) 
(registration requires additional credentials). If the certificate 
is valid and accepted (issued for the requester and signed by a 
trusted issuer), the registrar MUST proceed with the registration. 
If the certificate in the parameter is not accepted, the registrar 
MUST reject the corresponding registrations with the appropriate 
Failure Type: 


4 (Bad certificate): The certificate is corrupt, contains invalid 
signatures, etc. 


5 (Unsupported certificate): The certificate is of an unsupported 
type. 


6 (Certificate expired): The certificate is no longer valid. 


7 (Certificate other): The certificate could not be validated for 
some unspecified reason. 


8 (Unknown CA): The issuing certification authority (CA) certificate 
could not be located or is not trusted. 


After successful authorization, the registrar includes a REG_RESPONSE 
parameter in its response, which contains the service type(s) for 
which it has authorized registration, and zero or more REG _FAILED 
parameters containing the service type(s) for which it has not 
authorized registration or registration has failed for other reasons. 
This response can be either an R2 or an UPDATE message, respectively, 
depending on whether the registration was requested during the base 
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exchange or using an existing association. In particular, REG_FAILED 
with a Failure Type of zero indicates the service type(s) that 
requires further credentials for registration. 


If the registrar requires further authorization and the requester has 
additional credentials available, the requester SHOULD try to 
register again with the service after the HIP association has been 
established. 


Successful processing of a REG_RESPONSE parameter creates 
registration state at the requester. In a similar manner, successful 
processing of a REG_REQUEST parameter creates registration state at 
the registrar and possibly at the service. Both the requester and 
registrar can cancel a registration before it expires, if the 
services afforded by a registration are no longer needed by the 
requester or cannot be provided any longer by the registrar (for 
instance, because its configuration has changed). 


4+----- + 11 4+----- 4+----- + 
[| >| | sa | 
> Ale S 

R1 (REG_INFO:S1,S2,S3) +----- + 
| RQ | R | s2] 
| | 12 (REG_REQ:S1) | | | 
| |--------------------- >| +----- + 
[ooo DES 
| | R2 (REG_RESP:S1) | | | 
4+----- + 4+----- 4+----- + 


A requester (RQ) registers for service (S1) with a registrar (R) of 
services (S1), (S2), and (S3) with which it has no current HIP 


association 
4+----- + 4+----- 4+----- + 
| | UPDATE(REG_INFO:S) | | | 
| ees in ee 
[RO |--------------------- >| R | s | 
| | UPDATE (REG_REQ: S) | | | 

UPDATE (REG_RESP: S) 

<————— -—  - - 

4+----- + 4+----- 4+----- + 


A requester (RQ) registers for service (S) with a registrar (R) of 
services (S) with which it currently has a HIP association 
established 
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Parameter Formats and Processing 


This section describes the format and processing of the new 
parameters introduced by the HIP Registration Extension. The 
encoding of these new parameters conforms to the HIPv2 TLV format 
described in Section 5.2.1 of RFC7401 [RFC7401]. 


1. Encoding Registration Lifetimes with Exponents 


The HIP registration uses an exponential encoding of registration 
lifetimes. 


The special value 0 (zero) of the lifetime field MUST be interpreted 
as representing a special lifetime duration of 0 (zero) seconds and 
is used to request and grant cancellation of a registration. 


The non-zero values of the lifetime field used throughout this 
document MUST be interpreted as an exponent value representing a 
lifetime duration of 2%((lifetime - 64)/8) seconds. 


This allows a compact encoding of 255 different lifetime durations 
(in addition to the special lifetime duration of zero seconds) 
ranging from 2%(63/8) seconds (i.e., ~4 ms) to 2%(191/8) seconds 
(i.e., ~178 days) into an 8-bit integer field. 


-2. REG_INFO 


0 1 2 3 

012345678°90123456789012345678901 
fifo O fifi foto O patito O peg A papa p ig ipa pipette page gpg get 
Type | Length | 
Hifi fo fifi foto pi papi iti pi pogo t i pip git ipa pig ip ipa g git ge get 
Min Lifetime Max Lifetime | Reg Type #1 | Reg Type #2 | 
—foFofofifa foto fi pipet iti pi pop t i papi gigi pi page tipi page gigi gett 
| Reg Type #n | | 
O Padding + 
| 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+- 


+— +—+—+—+ 


Type 930 

Length Length in octets, excluding Type, Length, and Padding. 
Min Lifetime Minimum registration lifetime. 

Max Lifetime Maximum registration lifetime. 

Reg Type The registration types offered by the registrar. 


Other documents will define specific values for registration types. 
See Section 7 for more information. 
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Registrars include the parameter in R1 packets in order to announce 
their registration capabilities. The registrar SHOULD include the 

parameter in UPDATE packets when its service offering has changed. 

HIP_SIGNATURE_2 protects the parameter within the R1 packets. 


The registrar indicates the minimum and maximum registration lifetime 
that it is willing to offer to a requester. A requester SHOULD NOT 
request registration with a lifetime greater than the maximum 
registration lifetime or smaller than the minimum registration 
lifetime. 


4.3. REG_REQUEST 


0 1 2 3 
0:1:.2.34567%809012345678901:023456 78 "90 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Lifetime Reg Type #1 | Reg Type #2 | Reg Type #3 | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reg Type tn | | 
+-+-+-+-+-+-+-+-+ Padding + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+— + — + — + — + 


Type 932 

Length Length in octets, excluding Type, Length, and Padding. 
Lifetime Requested registration lifetime. 

Reg Type The preferred registration types in order of preference. 


Other documents will define specific values for registration types. 
See Section 7 for more information. 


A requester includes the REG_REQUEST parameter in I2 or UPDATE 
packets to register with a registrar's service(s). If the 
REG_REQUEST parameter is in an UPDATE packet, the registrar MUST NOT 
modify the registrations of registration types that are not listed in 
the parameter. Moreover, the requester MUST NOT include the 
parameter unless the registrar's Rl packet or latest received UPDATE 
packet has contained a REG_INFO parameter with the requested 
registration types. 


The requester MUST NOT include more than one REG_REQUEST parameter in 


its I2 or UPDATE packets, while the registrar MUST be able to process 
one or more REG_REQUEST parameters in received I2 or UPDATE packets. 
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When the registrar receives a registration with a lifetime that is 
either smaller or greater than the minimum or maximum lifetime, 
respectively, then it SHOULD grant the registration for the minimum 
or maximum lifetime, respectively. 


HIP_SIGNATURE protects the parameter within the 12 and UPDATE 
packets. 


4.4. REG_RESPONSE 


0 1 2 3 
Ob Be 31415 067 1890: Ay 22 3:45:06 008 9. OD 2: 345,6: 8:09:20: 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Reg Type #1 Reg Type #2 | Reg Type #3 | 


+ 

Lifetime | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

+ 


-+-+-+-+-+-+-+- 
Reg Type #n | | 
-+-+-+-+-+-+-+-+ Padding + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+ — + — +— + — + 


Type 934 

Length Length in octets, excluding Type, Length, and Padding. 
Lifetime Granted registration lifetime. 

Reg Type The granted registration types in order of preference. 


Other documents will define specific values for registration types. 
See Section 7 for more information. 


The registrar SHOULD include a REG_RESPONSE parameter in its R2 or 
UPDATE packet only if a registration has successfully completed. 


The registrar MUST NOT include more than one REG_RESPONSE parameter 
in its R2 or UPDATE packets, while the requester MUST be able to 
process one or more REG_RESPONSE parameters in received R2 or UPDATE 
packets. 


The requester MUST be prepared to receive any registration lifetime, 
including ones beyond the minimum and maximum lifetime indicated in 
the REG_INFO parameter. It MUST NOT expect that the returned 
lifetime will be the requested one, even when the requested lifetime 
falls within the announced minimum and maximum. 


HIP_SIGNATURE protects the parameter within the R2 and UPDATE 
packets. 
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4.5. REG_FAILED 


0 1 2 3 

O de 23-4 567-8 90 2 Be A TB OO AZ 3A O 7, B29: Oh 
A g ig 
Type | Length | 
—f-4-4-4-4-4-4-4-4-4- 4-4-4 4-4-4 ppp pi papi pi pip pig igi gigi gig 
Failure Type Reg Type #1 | Reg Type #2 | Reg Type +3 | 
a 4-4-4 4-4-4 ppp pip ip pip ipa gigi gigi gig it 
| Reg Type #n | | 
+-+-+-+-+-+-+-+-+ Padding + 
| 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+- 


+— + — + — + — + 


Type 936 

Length Length in octets, excluding Type, Length, and Padding. 

Failure Type Reason for failure. 

Reg Type The registration types that failed with the specified 
reason. 


Value Registration Failure Type 
0 Registration requires additional credentials 
1 Registration type unavailable 
2 Insufficient resources 


3 Invalid certificate 
9-200 Unassigned 
201-255 Reserved for Private Use 


Other documents will define specific values for registration types. 
See Section 7 for more information. 


Failure Type 0 (zero) indicates that the registrar requires 
additional credentials to authorize a requester to register with the 
registration types listed in the parameter. Failure Type 1 (one) 
indicates that the requested service type is unavailable at the 
registrar. Failure Type 2 indicates that the registrar does not 
currently have enough resources to register the requester for the 
service(s); when that is the case, the requester MUST NOT reattempt 
immediately to register for the same service(s) and MAY attempt to 
contact another registrar to register for the service(s). Failure 
Type 3 indicates that the registrar could not validate the 
certificate provided by the requester to register for the service(s); 
when that is the case, the requester MUST NOT reattempt to register 
for the same set of services while providing the same certificate and 
MAY attempt to register for the same set of services with a different 
certificate, or with a different set of services with the same 
certificate. 
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The registrar SHOULD include a REG_FAILED parameter in its R2 or 
UPDATE packet, if registration with the registration types listed has 
not completed successfully, and a requester is asked to try again 
with additional credentials. 


HIP_SIGNATURE protects the parameter within the R2 and UPDATE 
packets. 


5. Establishing and Maintaining Registrations 


Establishing and/or maintaining a registration may require additional 
information not available in the transmitted REG_REQUEST or 
REG_RESPONSE parameters. Therefore, registration type definitions 
MAY define dependencies for HIP parameters that are not defined in 
this document. Their semantics are subject to the specific 
registration type specifications. 


The minimum lifetime both registrars and requesters MUST support is 
10 seconds, while they SHOULD support a maximum lifetime of 120 
seconds, at least. These values define a baseline for the 
specification of services based on the registration system. They 
were chosen to be neither too short nor too long, and to accommodate 
for existing timeouts of state established in middleboxes (e.g., NATs 
and firewalls.) 


A zero lifetime is reserved for canceling purposes. Requesting a 
zero lifetime for a registration type is equal to canceling the 
registration of that type. A requester MAY cancel a registration 
before it expires by sending a REG_REQ to the registrar with a zero 
lifetime. A registrar SHOULD respond and grant a registration with a 
zero lifetime. A registrar (and an attached service) MAY cancel a 
registration before it expires, at its own discretion. However, if 
it does so, it SHOULD send a REG_RESPONSE with a zero lifetime to all 
registered requesters. 


6. Security Considerations 


This section discusses the threats on the HIP registration protocol 
and their implications on the overall security of HIP. In 
particular, it argues that the extensions described in this document 
do not introduce additional threats to HIP. 


The extensions described in this document rely on the HIP base 
exchange and do not modify its security characteristics, e.g., 
digital signatures or Hashed Message Authentication Code (HMAC). 
Hence, the only threat introduced by these extensions is related to 
the creation of soft registration state at the registrar. 
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Registrars act on a voluntary basis and are willing to accept being a 
Responder and then to create HIP associations with a number of 
potentially unknown hosts. Because they have to store HIP 
association state anyway, adding a certain amount of time-limited HIP 
registration states should not introduce any serious additional 
threats, especially because HIP registrars may Cancel registrations 
at any time at their own discretion, e.g., because of resource 
constraints during an attack. 


7. IANA Considerations 


This section is to be interpreted according to "Guidelines for 
Writing an IANA Considerations Section in RFCs" [RFC5226]. 


[RFC5203], obsoleted by this document, made the following definitions 
and reservations in the "Parameter Types" subregistry under "Host 
Identity Protocol (HIP) Parameters": 


Value Parameter Type Length 


930 REG_INFO variable 
932 REG_REQUEST variable 
934 REG_RESPONSE variable 
936 REG_FAILED variable 


In the "Parameter Types" subregistry under "Host Identity Protocol 
(HIP) Parameters", the references to the obsoleted [RFC5203] have 
been replaced with references to this document. 


[RFC5203], obsoleted by this document, requested the opening of the 
"Registration Types" subregistry under "Host Identity Protocol (HIP) 
Parameters", defined no registration types, but made the following 
reservations in that subregistry: 


Reg Type Service 


201-255 Reserved by IANA for private use 
Adding a new type requires new IETF specifications. 


In the "Registration Types" subregistry under "Host Identity Protocol 
(HIP) Parameters", references to the obsoleted [RFC5203] have been 
replaced with references to this document. 


[RFC5203], obsoleted by this document, requested the opening of the 
"Registration Failure Types" subregistry under "Host Identity 
Protocol (HIP) Parameters" and made the following definitions and 
reservations in that subregistry: 
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Failure Type Reason 

0 Registration requires additional credentials 
al Registration type unavailable 

201-255 Reserved by IANA for private use 


Adding a new type requires new IETF specifications. 


In the "Registration Failure Types" subregistry under "Host Identity 
Protocol (HIP) Parameters", references to the obsoleted [RFC5203] 
have been replaced with references to this document, and the 
following HIP Registration Failure Types have been added: 


Value Registration Failure Type 
2 Insufficient resources 
3 Invalid certificate 
4 Bad certificate 
5 Unsupported certificate 
6 Certificate expired 
7 Certificate other 
8 Unknown CA 
201-255 Reserved for Private Use 
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Appendix A. Changes from RFC 5203 
o Updated references to revised HIP specifications. 


o Added a new registration Failure Type for use in case of 
insufficient resources available at the HIP registrar. 


o Added requester authorization based on certificates and new 
registration Failure Types for invalid certificates. 
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